Guard BadImport's type-annotation move against unpositioned trees - #6083

Fixes #6074

Problem

BadImport.moveTypeAnnotations() unconditionally calls builder.delete(annotation) for every TYPE_USE-targeted annotation on a qualified type, then reinserts it before the qualified identifier. That delete requires a valid start/end source position for the annotation tree.

A record component's type-use annotation can be reached through javac's synthesized members (the desugared field/accessor/canonical constructor), whose copy of the annotation tree has no recorded end position. Building a Replacement from that position throws SourcePositionException (IllegalArgumentException before 2.48.0), aborting the whole compilation. BadImport is on by default, so this needs no special configuration to hit -- any record component whose type is an imported nested class, annotated with something carrying TYPE_USE in its @Target (e.g. Bean Validation's @NotNull), aborts the build.

Fix

Skip the move for annotations without an explicit source position, using ASTHelpers.hasExplicitSource() -- the same helper this codebase already uses elsewhere for exactly this check. The identifier is still qualified by the prefixWith() call in the caller; only the annotation relocation is skipped, so the fix stays useful instead of being dropped entirely.

Testing

Added BadImportTest#recordComponentWithTypeUseAnnotation_doesNotCrash, reproducing the record-component + TYPE_USE-annotation shape from the issue, adjacent to the existing nestedTypeUseAnnotation test this mirrors.

Honest caveat on local verification: I could not get a local Windows build past error_prone_check_api -- ErrorProneSignatureGenerator.java (a file this PR does not touch) fails with an enclosing instance that contains Types.SignatureGenerator is required when maven-compiler-plugin forks a javac subprocess, on both the exact JDK 25 GA build (25+36) and a later 25.0.4 patch, across two vendors (Temurin, Zulu). This reproduces on unmodified master too, so it's unrelated to this change -- and upstream CI is green on the commit I branched from (9fefe418), so it appears to be a Windows-specific forked-javac quirk on my machine rather than a real break. I was not able to run the new test locally as a result. The expected output in the added test is reasoned from the existing nestedTypeUseAnnotation test's behavior, not independently confirmed by a passing local run -- CI will be the first real signal on it, and I'll fix it promptly if it's wrong.